gccCrossStageStatic: enable dynamic libraries, rename it #238154
Conversation
|
I'm testing builds on a pretty large matrix of target platforms and gcc versions. In spite of this, I have the nagging feeling that this is going to break some obscure gcc version on an infrequently-used platform. I've tried to keep this PR
|
This comment was marked as outdated.
This comment was marked as outdated.
ghost
marked this pull request as ready for review
|
Everything tests fine, rebooted the laptop with a complete system (bootloader, kernel, userspace) built this way.
Edit: what I wrote in the previous paragraph is true, but I will do that in a separate PR after this one. The only thing we need gccWithoutTargetLibc to do is compile Getting |
ghost
marked this pull request as draft
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
the
2.status: merge conflict
github-actions
bot
removed
6.topic: steam
6.topic: nixos
ghost
changed the title
ghost
changed the title
|
Result of 2 packages blacklisted:
50 packages failed to build:
10 packages built:
|
ghost
mentioned this pull request
(Edit) Most (maybe all) of this is fixed by these two PRs (mostly the second one):
(edit) So this doesn't happen again: |
…tic-undo-the-hack gcc: revert "kludge to prevent mass-rebuild" from #238154
|
Bisect claims that one of these commits also broke I think |
|
And bisect claims that one of these commits also broke Don't see why immediately. |
Please add these to Also, I'm pretty sure none of us can afford S390 hardware. |
|
|
@ofborg build tests.cross.sanity |
|
Added |
ghost
mentioned this pull request
|
Another regression is |
|
I'm guessing the automatic backport failed and we never got backport to 23.05? Could this be backported, it would be nice, as I'm seeing the cross-compiled Wayland failing on runtime, and this PR fixes the issue |
|
Backport failed for Please cherry-pick the changes locally. git fetch origin release-23.05
git worktree add -d .worktree/backport-238154-to-release-23.05 origin/release-23.05
cd .worktree/backport-238154-to-release-23.05
git checkout -b backport-238154-to-release-23.05
ancref=$(git merge-base 931b8a4979df477c0baffc2544f593d7a9b32dcb 96a2f1b4e1315251f1916f64c4632dbf7eb40522)
git cherry-pick -x $ancref..96a2f1b4e1315251f1916f64c4632dbf7eb40522 |
|
This PR caused some regressions, so any potential backport should probably be okayed by the release managers before being merged. |
Best reviewed one commit at a time.
Motivation
Fix a serious bug in our
pkgsCrossbootstrap: cross compiled binaries segfault on pthread_cancel(3) due to missing libgcc_s.so #240484. This is the reason for the backport request.a. Also: Closes libgcc_s.so is missing from glibc when cross compiling #40797
Make our cross-compiler bootstrap look more like our
stdenvbootstrap, as a step towards unifying them.Summary
This PR allows
gccCrossStageStaticto build dynamically-linked libraries. Since is no longer restricted to building static libraries its name is no longer appropriate, and this PR also renames it to the more-accurategccWithoutTargetLibc.Detailed description of changes
By default, you can't build a gcc that knows how to create dynamic libraries unless you have already built the targetPlatform libc.
Because of this, our gcc cross-compiler is built in three stages:
Build a cross-compiler (gccCrossStageStatic) that can build only static libraries.
Use gccCrossStageStatic to compile the targetPlatform
libc.a.Use the targetPlatform
libc.ato build a fully-capable cross compiler.You might notice that this pattern looks very similar to what we do with
xgccandglibcin the stdenv bootstrap. Indeed it is! I would like to work towards getting the existing stdenv bootstrap to handle cross compilers as well. However we don't want to cripplestdenv.xgccby taking away its ability to build dynamic libraries.It turns out that the only thing gcc needs the targetPlatform libc for is to emit a DT_NEEDED for
-lcintolibgcc.so. That's it! And since we don't usegccCrossStageStaticto build anything other than libc, it's safe to omit theDT_NEEDEDbecause thatlibgccwill never be loaded by anything other thanlibc. Solibcwill already be in the process's address space.Other people have noticed this; crosstool-ng has been using this approach for a very long time:
https://github.com/crosstool-ng/crosstool-ng/blob/36ad0b17a732aaffe4701d5d8d410d6e3e3abba9/scripts/build/cc/gcc.sh#L638-L640
Closes #240484
Closes #240435
Things done
gcc6(cross from x86_64-linux)pkgsCross.aarch64-multiplatform.pkgsBuildTarget.gcc48.pkgsBuildTarget.gcc49.pkgsBuildTarget.gcc6.pkgsBuildTarget.gcc7.pkgsBuildTarget.gcc8.pkgsBuildTarget.gcc9.pkgsBuildTarget.gcc10.pkgsBuildTarget.gcc11.pkgsBuildTarget.gcc12.pkgsBuildTarget.gcc13